The present invention relates to client server communications interfaces and, in particular, to a communications interface between servers and service application programs running on a transaction server computer.
Telecommunications networks use computer platforms, called network intelligent platforms (xe2x80x9cNIPxe2x80x9d), to provide enhanced telephone services such as toll-free 800 call routing and virtual private network call routing. A telephone call originates in a local exchange carrier (xe2x80x9cLECxe2x80x9d) network and propagates from the LEC network to a switch, such as an originating switch or a terminating switch. For example, the originating switch processes the telephone call and routes the call to its destination. The destination may be in a different LEC or in a different type of telecommunications network, including a public switch telephone network (xe2x80x9cPSTNxe2x80x9d). The originating switch determines when processing for enhanced services is required for a telephone call. When processing for enhanced services is required, the originating switch opens a dialogue with a NIP, exchanging with the NIP higher-level protocol messages embedded within lower-level SS7 protocol messages. Signaling System No. 7 (xe2x80x9cSS7xe2x80x9d), is a well known dialogue-based communications protocol that may be used for communications with computing platforms such as the NIP. The data exchanged using the SS7 protocol interface between an originating switch and a NIP is commonly formatted into intelligent network application protocol (xe2x80x9cINAPxe2x80x9d) messages. At the end of the exchange of INAP messages that comprises a dialogue between an originating switch and a NIP, the NIP directs the originating switch to connect the telephone call to a final destination. In the event of an error, the originating switch will be directed to terminate the call. The exchange of INAP messages between originating switches and NIPs constitutes a telecommunications service protocol interface, the INAP protocol interface, implemented on top of the lower-level SS7 protocol interface.
A NIP contains several computers known as transaction servers. Transaction servers simultaneously execute two types of software programs. The first type of program is a Transactions Capability Application Part (xe2x80x9cTCAPxe2x80x9d) server that receives messages from originating switches and that sends response messages back to the originating switches. A TCAP server extracts INAP messages from the SS7 protocol messages that the TCAP server receives from originating switches and forwards the INAP messages to service application programs, the second type of software program that runs on transaction servers. Service application programs process enhanced service requests from originating switches and communicate with the originating switch by exchanging INAP messages. Service application programs send response INAP messages back to TCAP servers which, in turn, direct the response messages back to the originating switches.
Service application programs must include specialized communications software for handling the exchange of INAP messages through the INAP protocol interface. In particular, this specialized communications software must keep track of the originating switch that sent an incoming message as well as the TCAP server through which the incoming message passed so that responses to the incoming message can be returned to the same originating switch that sent the incoming message through the same TCAP server through which the incoming message passed. The specialized communications software must also maintain state information about each separate dialogue that is conducted between an originating switch and a service application. A dialogue can extend over the exchange of many different INAP messages. In addition to the INAP messages, Integrated Services Digital Network (xe2x80x9cISDNxe2x80x9d) user part (xe2x80x9cISUPxe2x80x9d) messages may also be embedded within SS7 protocol messages. The specialized communications software included in service applications must therefore detect ISUP messages and handle them as well. The specialized communications software must handle the different encoding and decoding schemes used for the data included in INAP messages and must process many separate fields within the INAP message header contained in a typical INAP message. The specialized communications software must also maintain detailed configuration information about the particular transaction server on which the service application is running.
When a new service application program is developed, the specialized communication software is generally written specifically for the new service application program. When the configuration of the transaction server is changed or modified, the specialized communications software of each service application program that runs on that transaction server must correspondingly be modified to include updated configuration information that the specialized communications software uses to route messages to and from NIP. As a result, the maintenance of existing service applications and the creation of new service applications are often costly and complicated tasks. A need has therefore been recognized for abstracting the communications interface between TCAP servers and service applications so that the service applications need not themselves include specialized communications software.
The present invention provides an abstract, object-oriented encapsulation of the communications interface between intermediary, lower-level protocol handlers, such as TCAP servers, and higher-level telecommunications service providers, such as the service application programs that run on transaction server computers within an enhanced services platform, such as a NIP. A TCAP server receives a TCAP message that includes a request INAP message from a telephone network switch seeking an enhanced service provided by the NIP. The request INAP message includes a request type and request data. The TCAP server extracts the request INAP message from the TCAP message and encapsulates the request INAP message in a message encapsulation interface object. The TCAP server then passes the message encapsulation interface object to a service application program by calling a transfer method of an object transfer interface object within the TCAP server. The service application program receives the message encapsulation interface object by calling a transfer method of an object transfer interface object within the service application program. The service application program then obtains the type and request data from the message encapsulation interface object by calling methods of the message encapsulation interface object.
The abstract, object-oriented communications interface of the present invention greatly simplifies the development and maintenance of service application programs. The specialized INAP communications handlers that were formerly developed for each different service application program can now be replaced by including in each service application program the library routines of the abstract, object-oriented communications interface of the present invention.